[レポート] Amazon Aurora deep dive ～性能向上の仕組みと最新アップデート～ #AWSSummit

AWS Summit Tokyo 2016のセッション資料が最近になって公開されました。

http://aws.amazon.com/jp/summit2016-report/

今回は、その中から「Amazon Aurora deep dive ～性能向上の仕組みと最新アップデート～」についてレポートします。

セッション資料

タイトル

Amazon Aurora deep dive ～性能向上の仕組みと最新アップデート～

動画

 

セッション資料

http://media.amazonwebservices.com/jp/summit2016/2D-02.pdf

スピーカーについて

• 星野 豊
• アマゾン ウェブ サービス ジャパン株式会社
• データベースの専属ソリューションズ・アーキテクト
• San Francisco、Seatleなどにあるデータベース開発チームと一緒に仕事することが多い
• メディア系などかなり大規模なサービスが担当

セッションの内容

2016/06/02 現在の情報

Amazon Aurora について

Amazon RDS のエンジンの一つ

Amazon Auroraの大きな特徴

• ハイパフォーマンス
• スケーラブル
• MySQL5.6互換
• セキュリティにも配慮
• フルマネージド
• 高可用性・高耐久性

なぜこの時代に Amazon はリレーショナルデータベースを作ったのか?

現在のRDB

• 1970年代のデータベースのコアとなる論文をもとに作られている
• さまざまなハードウェアで動くことを前提に大きくてモノリシックなアプリケーションとして動作する。

Amazon Aurora

• クラウドを前提にデータベースを再構築
• 4年を開発を経て2015年にリリース

利用事例

Amazon 始まって以来、最速で利用が伸びているサービス

国内の顧客例

• Grani(ゲーム)
• Live Dwango Reader(RSS リーダー)
• 毎日新聞(新聞社)
• Zaim(家計簿)

アーキテクチャ

Service Oriented Architecture

• SQLとトランザクション
• キャッシング
• ロギング・ストレージ

など、複数レイヤーにまたがるService Oriented Architecture(SOA)として動作

疎結合な構成

キャッシュレイヤを分離した理由

• キャッシュをデータベースプロセスの外に移動
• パッチ適用・障害などの理由でデータベースのリスタートが発生しても、キャシュが残る。
• つまり、暖気せずとも、パフォーマンスへのインパクトがない。

セキュリティ

• VPC中のみに動作
• AWS のFW(Security Group, NACL)の機能がそのまま適用可能
• Encryption at rest。データ保存時は暗号化させることができる
• ノードへの直接アクセスは不可

Auroraのストレージ

• 3つの AZ に6つのデータコピーを持ち、可用性を上げている
• ディスクパフォーマンスに影響なく、S3にストリーミング(増分)バックアップ
• 64TBまでパフォーマンスや可用性に影響なく、シームレスにスケールアップ
• データ・ディスクが壊れた場合、自動的に検知して修復する仕組みをストレージレイヤーでもっている(堅牢性のあるストレージ)

Log Structured Storage

• ログファイルのような追記型のストレージ・システム
• 追記型のため、追加された、新しいデータだけをS3への増分バックアップできる

ディスク障害検知と修復

• データは 3AZ にまたがり6つのコピーを持つ
• 2コピーに障害が起こっても、読み書きに影響はない
• 3コピーに障害が起こっても、読み込みに影響はない
• 1 AZ で障害が起きても、Aurora は動き続け、データロストも発生しない

IO traffic in Aurora(ストレージノード)

どうやってデータを6本のディスクにコピー作るのか?

• プライマリインスタンスからデータを受け取り、メモリのキューに追加。
• 一定量が貯まると、SSD に書き込む。
• 6本のうち4本のコピーに成功したら書き込み成功とみなし、ディスク Latency を抑えている
• 残り2本へのコピーはゴシッププロトコルでディスク同士が協調して正しい状態に持っていく。
• 自動修復も同じ仕組が利用される。

レプリケーション方法

• MySQLはバイナリーログを利用
• Auroraはマスタ・スレーブが同じディスク(共有ストレージのようなもの)を見ている。そのため、レプリカ遅延が少なく、データ同期のオーバーヘッドも少ない。

レプリケーション遅延

大きなテーブルを更新すると、MySQL だとバイナリーログの転送により、レプリケーション遅延が増加する

Auroraでは共有ストレージの仕組みにより、QPS, データサイズ、テーブルサイズによらず、レプリカログは10ms-20ms程度

フェイルオーバーでデータロストは発生するのか?

MySQL では、バイナリーログの転送が終わっていなければ、マスターノードの障害がデータロスにつながる。

Aurora では、マスターノードで書き込みが完了していれば、共有ストレージのおかげでデータロストはかなり最小限に抑えられている

Aurora の新しいメトリクス画面

• Throuput/Latency/Cache Hit Ratioなど
• 課金に関わるメトリクス

フェイルオーバとリカバリ

フェイルオーバとリプレースの仕組み

• 他の RDS エンジンと比べてもかなり高速にフェイルオーバーする。
• Aurora のフェイルオーバー速度はどんどん高速化されており、リードレプリカが存在する場合は45秒程度。
• レプリカが存在しない場合は、DBインスタンスの作成が必要なので15分程度を要する
• Multi-AZにしていれば、AZダウンしてもサービづを提供し続けられる。

クラスタエンドポイント

• つねに writer ノードを指し示す DNS エンドポイント。
• フェイルオーバー時もエンドポイントの変更は発生せず、CNAMEの指し示す先だけが変わる。
• Read/Write splitting をしている場合、Writer はこのクラスタエンドポイントを参照しておけば良い。
• Reader に関しては、インスタンスごとにインスタンスエンドポイントが存在するので、そちらを参照する。

Aurora 以外の RDS ではクラスタエンドポイントがなかったため、フェイルオーバー時にはマスタの書き換えなどが発生していた

フェイルオーバーの注意点

フェイルオーバーは高速に行われるが

Aurora は共有ストレージ形式だが、スレーブが持っているディスショナリキャッシュをパージするために 10ms-20ms のレプリケーションラグが発生する。

• フェイルオーバーが発生すると、新しいマスタノードに対してキャッシュの整合性を取るために、すべてのレプリカが5s-10s程度かけて再起動する(瞬断が発生する)。
• クライアントは、フェイルオーバーその他の瞬断に備えて、リトライ処理を入れること。
• 再起動が発生しないようにすることも、開発チームと検討している

高速でより予測可能なフェイルオーバー時間

どうやって早いフェイルオーバーが実現されているのか?

MySQL

• データサイズ
• チェックポイントが打たれたタイミング

などによってクラッシュリカバリの時間が予測できない

Aurora

• Auroraのプロセスではクラッシュリカバリは行わない
• ストレージノード側でクラッシュリカバリを常に行っている
• 最大でも40秒あれば、アプリケーションからのコネクションを受け付けるようになる。

Streaming snapshot と PITR

• ストリーミングバックアップをS3に行っている。
• データが Aurora ストレージに書き込まれる瞬間にS3にバックアップが取られている。

ドキュメントではPITRの起点を「5分前から」としているが、タイミングによっては「1分前」など、より最近のポイントからのリカバリも可能。

The latest restorable time for a DB instance is typically within 5 minutes of the current time. http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html

継続的なバックアップ

フルスナップショットと差分バックアップで構成される。

• Aurora は 10GBずつの小さいブロック(セグメント)単位でストレージに格納している。
• リストア時には最後のフルスナップショットに以降のセグメントを並列で適用する。

SQLによるフェイルオーバのテスト

Aurora は ALTER SYSTEM 文により ノード・ディスク・ネットワーク障害をシミュレーション可能

Aurora の開発・テスト段階から、Netflix の Chaos Monkey のような Fault Injection 手法 を実践しており、AZ 障害、データノード障害が発生しても、動き続けるか確認している。

チューニングとパフォーマンス

5x faster than RDS MySQL 5.6 & 5.7

ベンチマークは FAQ の What does "five times the performance of MySQL" mean? にも記載がある。

再現性のある手順も公開されている。

Amazon Aurora Performance Assessment

• GAリリースした時 50万 QPSだった。
• 半年たって 60万 QPS を達成した。

インスタンスサイズによるスケール

Aurora はインスタンスサイズに比例してスケール

Aurora は MySQL では苦手だったメニーコア環境でも性能を発揮するような作りになっている。

Beyond benchmarks

Auroraは実際のワークロードでパフォーナンスが出るようにチューニングされている。

チューニング指針

• 標準のパラメーターグループをそのまま使う
• スレッド、innodb などもそのままでOK
• Auroraはマシンリソースを使い切る
• CPU・メモリ利用率が高くても、性能が落ちるわけではない。
• ベンチマーク時はCPU・メモリ利用率のようなインスタンスリソースではなく、クエリレイテンシ、スループット、buffer poolのcache hit ratio などを注目すること。

チューニング指針

• パフォーマンスが出なかった時は一つ上のインスタンスタイプを使う。
• それでもパフォーマンスが出なかった時は、パラメーターのチューニングを行う。
• なによりも、適切なインスタンスタイプを選択すること。

チューニングTips

Aurora は特徴的なストレージを持っているため、1トランザクションで大量の更新を行ったり、大量データのシーケンシャルリードするような処理は MySQL よりパフォーマンスが出にくい傾向がある。

クエリーを分割して並列実行させると、性能改善する。

性能向上の為に行っていること

同じワークロードを MySQL/Aurora に対して流す

Aurora は追記型ストレージや効率的な書き込みのおかげで MySQL よりトランザクション数が増えるのに ディスクI/Oが減る。

スレッドプール

MariaDB/MySQL Enterprise Edition にあるスレッドプールが Aurora にも独自実装されている。

• Aurora のコネクション数は動的に変化
• 接続クライアントが少ない時の CPU リソースは SQL 実行などを優先させる。

非同期グループコミット

更新差分をまとめてストレージに送る

過去数ヶ月で改善したこと

パフォーマンス改善に向けて、いろいろ行っている。

新機能

• クロスリージョンレプリケーション対応
• ローカルタイムゾーン
• フェイルオーバー順の指定
• Cluster View
• 拡張モニタリング
• Encryption at Rest
• パフォーマンスの改善
• Lab mode

まとめ

• Amazon Aurora はクラウド時代にAmazonが再設計したRDBMS
• クエリ実行並列度・データサイズが大きい環境で性能を発揮
• お客様環境でよくあるワークロードに向けてチューニングされている。
• 高可用性・高速フェイルオーバーに向けて今後も技術的チャレンジを行っていく。

毎日新聞、Live Dwango Reader など MySQL からの移行がスムーズ。 Grani はパフォーマンス向上、コスト削減を達成。

Auroraを使って何か問題があれば、フィードバックをいただき、Auroraの開発チームと密に連携して、改善に向けて働きかけていく。

個人感想

まさに Deep Dive な内容で、Aurora に限らず、リレーショナルデータベースを触っているアプリ・インフラ双方の多くのエンジニアにとって、非常に有益なセッションではないでしょうか。